WebAssembly Core Specification

1.1.1. Design Goals

The design goals of WebAssembly are the following:

• Fast, safe, and portable semantics:

  • Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.

  • Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.

  • Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.

  • Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.

  • Language-independent: does not privilege any particular language, programming model, or object model.

  • Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.

  • Open: programs can interoperate with their environment in a simple and universal manner.

• Efficient and portable representation:

  • Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.

  • Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.

  • Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.

  • Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.

  • Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.

  • Portable: makes no architectural assumptions that are not broadly supported across modern hardware.

WebAssembly code is also intended to be easy to inspect and debug, especially in environments like web browsers, but such features are beyond the scope of this specification.

1.1.2. Scope

At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). As such, it has many use cases and can be embedded in many different environments. To encompass their variety and enable maximum reuse, the WebAssembly specification is split and layered into several documents.

This document is concerned with the core ISA layer of WebAssembly. It defines the instruction set, binary encoding, validation, and execution semantics, as well as a textual representation. It does not, however, define how WebAssembly programs can interact with a specific environment they execute in, nor how they are invoked from such an environment.

Instead, this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.

1.1.3. Security Considerations

WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.

Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.

1.1.4. Dependencies

WebAssembly depends on two existing standards:

• [IEEE-754-2019], for the representation of floating-point data and the semantics of respective numeric operations.

• [UNICODE], for the representation of import/export names and the text format.

However, to make this specification self-contained, relevant aspects of the aforementioned standards are defined and formalized as part of this specification, such as the binary representation and rounding of floating-point values, and the value range and UTF-8 encoding of Unicode characters.

1.2.1. Concepts

WebAssembly encodes a low-level, assembly-like programming language. This language is structured around the following concepts.

Values

WebAssembly provides only four basic number types. These are integers and [IEEE-754-2019] numbers, each in 32 and 64 bit width. 32-bit integers also serve as Booleans and as memory addresses. The usual operations on these types are available, including the full matrix of conversions between them. There is no distinction between signed and unsigned integer types. Instead, integers are interpreted by respective operations as either unsigned or signed in two’s complement representation.

In addition to these basic number types, there is a single 128 bit wide vector type representing different types of packed data. The supported representations are four 32-bit, or two 64-bit [IEEE-754-2019] numbers, or different widths of packed integer values, specifically two 64-bit integers, four 32-bit integers, eight 16-bit integers, or sixteen 8-bit integers.

Finally, values can consist of opaque references that represent pointers towards different sorts of entities. Unlike with other types, their size or representation is not observable.

Instructions

The computational model of WebAssembly is based on a stack machine. Code consists of sequences of instructions that are executed in order. Instructions manipulate values on an implicit operand stack [1] and fall into two main categories. Simple instructions perform basic operations on data. They pop arguments from the operand stack and push results back to it. Control instructions alter control flow. Control flow is structured, meaning it is expressed with well-nested constructs such as blocks, loops, and conditionals. Branches can only target such constructs.

Traps

Under some conditions, certain instructions may produce a trap, which immediately aborts execution. Traps cannot be handled by WebAssembly code, but are reported to the outside environment, where they typically can be caught.

Functions

Code is organized into separate functions. Each function takes a sequence of values as parameters and returns a sequence of values as results. Functions can call each other, including recursively, resulting in an implicit call stack that cannot be accessed directly. Functions may also declare mutable local variables that are usable as virtual registers.

Tables

A table is an array of opaque values of a particular reference type. It allows programs to select such values indirectly through a dynamic index operand. Thereby, for example, a program can call functions indirectly through a dynamic index into a table. This allows emulating function pointers by way of table indices.

Linear Memory

A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.

Modules

A WebAssembly binary takes the form of a module that contains definitions for functions, tables, and linear memories, as well as mutable or immutable global variables. Definitions can also be imported, specifying a module/name pair and a suitable type. Each definition can optionally be exported under one or more names. In addition to definitions, modules can define initialization data for their memories or tables that takes the form of segments copied to given offsets. They can also define a start function that is automatically executed.

Embedder

A WebAssembly implementation will typically be embedded into a host environment. This environment defines how loading of modules is initiated, how imports are provided (including host-side definitions), and how exports can be accessed. However, the details of any particular embedding are beyond the scope of this specification, and will instead be provided by complementary, environment-specific API definitions.

1.2.2. Semantic Phases

Conceptually, the semantics of WebAssembly is divided into three phases. For each part of the language, the specification specifies each of them.

Decoding

WebAssembly modules are distributed in a binary format. Decoding processes that format and converts it into an internal representation of a module. In this specification, this representation is modelled by abstract syntax, but a real implementation could compile directly to machine code instead.

Validation

A decoded module has to be valid. Validation checks a number of well-formedness conditions to guarantee that the module is meaningful and safe. In particular, it performs type checking of functions and the instruction sequences in their bodies, ensuring for example that the operand stack is used consistently.

Execution

Finally, a valid module can be executed. Execution can be further divided into two phases:

Instantiation. A module instance is the dynamic representation of a module, complete with its own state and execution stack. Instantiation executes the module body itself, given definitions for all its imports. It initializes globals, memories and tables and invokes the module’s start function if defined. It returns the instances of the module’s exports.

Invocation. Once instantiated, further WebAssembly computations can be initiated by invoking an exported function on a module instance. Given the required arguments, that executes the respective function and returns its results.

Instantiation and invocation are operations within the embedding environment.

2.1.1. Grammar Notation

The following conventions are adopted in defining grammar rules for abstract syntax.

• Terminal symbols (atoms) are written in sans-serif font or in symbolic form: $$\mathsf{i}32$$, $$\mathsf{nop}$$, $$\to$$, $$[,]$$.

• Nonterminal symbols are written in italic font: $$valtype$$, $$instr$$.

• $${\mathrm{A}}^{\mathrm{n}}$$ is a sequence of $$\mathrm{n}\ge 0$$ iterations of $$\mathrm{A}$$.

• $${\mathrm{A}}^{\ast }$$ is a possibly empty sequence of iterations of $$\mathrm{A}$$. (This is a shorthand for $${\mathrm{A}}^{\mathrm{n}}$$ used where $$\mathrm{n}$$ is not relevant.)

• $${\mathrm{A}}^{+}$$ is a non-empty sequence of iterations of $$\mathrm{A}$$. (This is a shorthand for $${\mathrm{A}}^{\mathrm{n}}$$ where $$\mathrm{n}\ge 1$$.)

• $${\mathrm{A}}^{?}$$ is an optional occurrence of $$\mathrm{A}$$. (This is a shorthand for $${\mathrm{A}}^{\mathrm{n}}$$ where $$\mathrm{n}\le 1$$.)

• Productions are written $$\begin{array}{lrrl}& sym& ::=& A_1|\dots |A_n\end{array}$$.

• Large productions may be split into multiple definitions, indicated by ending the first one with explicit ellipses, $$\begin{array}{lrrl}& sym& ::=& A_1|\dots \end{array}$$, and starting continuations with ellipses, $$\begin{array}{lrrl}& sym& ::=& \dots |A_2\end{array}$$.

• Some productions are augmented with side conditions, “$$\text{if}condition$$”, that provide a shorthand for a combinatorial expansion of the production into many separate cases.

• If the same meta variable or non-terminal symbol appears multiple times in a production, then all those occurrences must have the same instantiation. (This is a shorthand for a side condition requiring multiple different variables to be equal.)

2.1.2. Auxiliary Notation

When dealing with syntactic constructs the following notation is also used:

• $$ϵ$$ denotes the empty sequence.

• $$|s|$$ denotes the length of a sequence $$\mathrm{s}$$.

• $$\mathrm{s}[\mathrm{i}]$$ denotes the $$\mathrm{i}$$-th element of a sequence $$\mathrm{s}$$, starting from $$0$$.

• $$\mathrm{s}[\mathrm{i}:\mathrm{n}]$$ denotes the sub-sequence $$\mathrm{s}[\mathrm{i}]\dots \mathrm{s}[\mathrm{i}+\mathrm{n}-1]$$ of a sequence $$\mathrm{s}$$.

• $$\mathrm{s}[[\mathrm{i}]=\mathrm{A}]$$ denotes the same sequence as $$\mathrm{s}$$, except that the $$\mathrm{i}$$-th element is replaced with $$\mathrm{A}$$.

• $$\mathrm{s}[[\mathrm{i}:\mathrm{n}]={\mathrm{A}}^{\mathrm{n}}]$$ denotes the same sequence as $$\mathrm{s}$$, except that the sub-sequence $$\mathrm{s}[\mathrm{i}:\mathrm{n}]$$ is replaced with $${\mathrm{A}}^{\mathrm{n}}$$.

• $${\mathrm{s}}_1\oplus {\mathrm{s}}_2$$ denotes the sequence $${\mathrm{s}}_1$$ concatenated with $${\mathrm{s}}_2$$; this is equivalent to $${\mathrm{s}}_1{\mathrm{s}}_2$$, but used for clarity.

• $$⨁{\mathrm{s}}^{\ast }$$ denotes the flattened sequence, formed by concatenating all sequences $${\mathrm{s}}_{\mathrm{i}}$$ in $${\mathrm{s}}^{\ast }$$.

• $$\mathrm{A}\in \mathrm{s}$$ denotes that $$\mathrm{A}$$ is a member of the sequence $$\mathrm{s}$$, that is, $$\mathrm{s}$$ is of the form $${\mathrm{s}}_1\mathrm{A}{\mathrm{s}}_2$$ for some sequences $${\mathrm{s}}_1$$, $${\mathrm{s}}_2$$.

Moreover, the following conventions are employed:

• The notation $${\mathrm{x}}^{\mathrm{n}}$$, where $$\mathrm{x}$$ is a non-terminal symbol, is treated as a meta variable ranging over respective sequences of $$\mathrm{x}$$ (similarly for $${\mathrm{x}}^{\ast }$$, $${\mathrm{x}}^{+}$$, $${\mathrm{x}}^{?}$$).

• When given a sequence $${\mathrm{x}}^{\mathrm{n}}$$, then the occurrences of $$\mathrm{x}$$ in an iterated sequence $$(\dots \mathrm{x}\dots {)}^{\mathrm{n}}$$ are assumed to denote the individual elements of $${\mathrm{x}}^{\mathrm{n}}$$, respectively (similarly for $${\mathrm{x}}^{\ast }$$, $${\mathrm{x}}^{+}$$, $${\mathrm{x}}^{?}$$). This implicitly expresses a form of mapping syntactic constructions over a sequence.

• $${\mathrm{e}}^{\mathrm{i}<\mathrm{n}}$$ denotes the same sequence as $${\mathrm{e}}^{\mathrm{n}}$$, but implicitly also defines $${\mathrm{i}}^{\mathrm{n}}$$ to be the sequence of values $$0$$ to $$(\mathrm{n}-1)$$.

Productions of the following form are interpreted as records that map a fixed set of fields $${\mathsf{field}}_{\mathrm{i}}$$ to “values” $${\mathrm{A}}_{\mathrm{i}}$$, respectively:

The following notation is adopted for manipulating such records:

• Where the type of a record is clear from context, empty fields with value $$ϵ$$ are often omitted.

• $$\mathrm{r}.\mathsf{field}$$ denotes the contents of the $$\mathsf{field}$$ component of $$\mathrm{r}$$.

• $$\mathrm{r}[.\mathsf{field}=\mathrm{A}]$$ denotes the same record as $$\mathrm{r}$$, except that the value of the $$\mathsf{field}$$ component is replaced with $$\mathrm{A}$$.

• $$\mathrm{r}[.\mathsf{field}=\oplus {\mathrm{A}}^{\ast }]$$ denotes the same record as $$\mathrm{r}$$, except that $${\mathrm{A}}^{\ast }$$ is appended to the sequence value of the $$\mathsf{field}$$ component, that is, it is short for $$\mathrm{r}[.\mathsf{field}=\mathrm{r}.\mathsf{field}\oplus {\mathrm{A}}^{\ast }]$$.

• $${\mathrm{r}}_1\oplus {\mathrm{r}}_2$$ denotes the composition of two identically shaped records by concatenating each field of sequences point-wise:

  $$\{{\mathsf{field}}_1{\mathrm{A}}_1^{\ast },{\mathsf{field}}_2{\mathrm{A}}_2^{\ast },\dots \}\oplus \{{\mathsf{field}}_1{\mathrm{B}}_1^{\ast },{\mathsf{field}}_2{\mathrm{B}}_2^{\ast },\dots \}=\{{\mathsf{field}}_1({\mathrm{A}}_1^{\ast }\oplus {\mathrm{B}}_1^{\ast }),{\mathsf{field}}_2({\mathrm{A}}_2^{\ast }\oplus {\mathrm{B}}_2^{\ast }),\dots \}$$

• $$⨁{\mathrm{r}}^{\ast }$$ denotes the composition of a sequence of records, respectively; if the sequence is empty, then all fields of the resulting record are empty.

The update notation for sequences and records generalizes recursively to nested components accessed by “paths” $$\begin{array}{lrrl}& pth& ::=& ([i]\mid .\mathsf{field}{)}^{+}\end{array}$$:

• $$\mathrm{s}[[\mathrm{i}]pth=\mathrm{A}]$$ is short for $$\mathrm{s}[[\mathrm{i}]=\mathrm{s}[\mathrm{i}][pth=\mathrm{A}]]$$,

• $$\mathrm{r}[.\mathsf{field}pth=\mathrm{A}]$$ is short for $$\mathrm{r}[.\mathsf{field}=\mathrm{r}.\mathsf{field}[pth=\mathrm{A}]]$$.

2.1.3. Lists

Lists are bounded sequences of the form $${\mathrm{A}}^{\mathrm{n}}$$ (or $${\mathrm{A}}^{\ast }$$), where the $$\mathrm{A}$$ can either be values or complex constructions. A list can have at most $$2^{32}-1$$ elements.

2.2.1. Bytes

The simplest form of value are raw uninterpreted bytes. In the abstract syntax they are represented as hexadecimal literals.

2.2.2. Integers

Different classes of integers with different value ranges are distinguished by their bit width $$\mathrm{N}$$ and by whether they are unsigned or signed.

The class $$i$$ defines uninterpreted integers, whose signedness interpretation can vary depending on context. In the abstract syntax, they are represented as unsigned values. However, some operations convert them to signed based on a two’s complement interpretation.

2.2.3. Floating-Point

Floating-point data represents 32 or 64 bit values that correspond to the respective binary formats of the [IEEE-754-2019] standard (Section 3.3).

Every value has a sign and a magnitude. Magnitudes can either be expressed as normal numbers of the form $${\mathrm{m}}_0.{\mathrm{m}}_1{\mathrm{m}}_2\dots {\mathrm{m}}_{\mathsf{m}}\cdot 2^{\mathrm{e}}$$, where $$\mathrm{e}$$ is the exponent and $$\mathrm{m}$$ is the significand whose most significant bit $${\mathrm{m}}_0$$ is $$1$$, or as a subnormal number where the exponent is fixed to the smallest possible value and $${\mathrm{m}}_0$$ is $$0$$; among the subnormals are positive and negative zero values. Since the significands are binary values, normals are represented in the form $$(1+\mathrm{m}\cdot 2^{-\mathrm{M}})\cdot 2^{\mathrm{e}}$$ in the abstract syntax, where $$\mathrm{M}$$ is the bit width of $$\mathrm{m}$$; similarly for subnormals.

Possible magnitudes also include the special values $$\infty$$ (infinity) and $$\mathsf{nan}$$ (NaN, not a number). NaN values have a payload that describes the mantissa bits in the underlying binary representation. No distinction is made between signalling and quiet NaNs.

where $$\begin{array}{lcl}M& =& \mathrm{signif}(N)\end{array}$$ and $$\begin{array}{lcl}E& =& \mathrm{expon}(N)\end{array}$$ with

A canonical NaN is a floating-point value $$\pm \mathsf{nan}({\mathrm{canon}}_{\mathrm{N}})$$ where $${\mathrm{canon}}_{\mathrm{N}}$$ is a payload whose most significant bit is $$1$$ while all others are $$0$$:

An arithmetic NaN is a floating-point value $$\pm \mathsf{nan}(\mathrm{m})$$ with $$\mathrm{m}\ge {\mathrm{canon}}_{\mathrm{N}}$$, such that the most significant bit is $$1$$ while all others are arbitrary.

2.2.4. Vectors

Numeric vectors are 128-bit values that are processed by vector instructions (also known as SIMD instructions, single instruction multiple data). They are represented in the abstract syntax using $$u128$$. The interpretation of lane types (integer or floating-point numbers) and lane sizes are determined by the specific instruction operating on them.

2.2.5. Names

Names are sequences of characters, which are scalar values as defined by [UNICODE] (Section 2.4).

Due to the limitations of the binary format, the length of a name is bounded by the length of its UTF-8 encoding.

2.3.1. Number Types

Number types classify numeric values.

The types $$\mathsf{i}32$$ and $$\mathsf{i}64$$ classify 32 and 64 bit integers, respectively. Integers are not inherently signed or unsigned, their interpretation is determined by individual operations.

The types $$\mathsf{f}32$$ and $$\mathsf{f}64$$ classify 32 and 64 bit floating-point data, respectively. They correspond to the respective binary floating-point representations, also known as single and double precision, as defined by the [IEEE-754-2019] standard (Section 3.3).

Number types are transparent, meaning that their bit patterns can be observed. Values of number type can be stored in memories.

2.3.2. Vector Types

Vector types classify vectors of numeric values processed by vector instructions (also known as SIMD instructions, single instruction multiple data).

The type $$\mathsf{v}128$$ corresponds to a 128 bit vector of packed integer or floating-point data. The packed data can be interpreted as signed or unsigned integers, single or double precision floating-point values, or a single 128 bit type. The interpretation is determined by individual operations.

Vector types, like number types are transparent, meaning that their bit patterns can be observed. Values of vector type can be stored in memories.

2.3.3. Type Uses

A type use is the use site of a type index referencing a composite type defined in a module. It classifies objects of the respective type.

The syntax of type uses is extended with additional forms for the purpose of specifying validation and execution.

2.3.4. Heap Types

Heap types classify objects in the runtime store. There are three disjoint hierarchies of heap types:

• function types classify functions,

• aggregate types classify dynamically allocated managed data, such as structures, arrays, or unboxed scalars,

• external types classify external references possibly owned by the embedder.

The values from the latter two hierarchies are interconvertible by ways of the $$\mathsf{extern}.convert\_any$$ and $$\mathsf{any}.convert\_extern$$ instructions. That is, both type hierarchies are inhabited by an isomorphic set of values, but may have different, incompatible representations in practice.

A heap type is either abstract or concrete. A concrete heap type consists of a type use that classifies an object of the respective type defined in a module. Abstract types are denoted by individual keywords.

The type $$\mathsf{func}$$ denotes the common supertype of all function types, regardless of their concrete definition. Dually, the type $$\mathsf{nofunc}$$ denotes the common subtype of all function types, regardless of their concrete definition. This type has no values.

The type $$\mathsf{exn}$$ denotes the common supertype of all exception references. This type has no concrete subtypes. Dually, the type $$\mathsf{noexn}$$ denotes the common subtype of all forms of exception references. This type has no values.

The type $$\mathsf{extern}$$ denotes the common supertype of all external references received through the embedder. This type has no concrete subtypes. Dually, the type $$\mathsf{noextern}$$ denotes the common subtype of all forms of external references. This type has no values.

The type $$\mathsf{any}$$ denotes the common supertype of all aggregate types, as well as possibly abstract values produced by internalizing an external reference of type $$\mathsf{extern}$$. Dually, the type $$\mathsf{none}$$ denotes the common subtype of all forms of aggregate types. This type has no values.

The type $$\mathsf{eq}$$ is a subtype of $$\mathsf{any}$$ that includes all types for which references can be compared, i.e., aggregate values and $$\mathsf{i}31$$.

The types $$\mathsf{struct}$$ and $$\mathsf{array}$$ denote the common supertypes of all structure and array aggregates, respectively.

The type $$\mathsf{i}31$$ denotes unboxed scalars, that is, integers injected into references. Their observable value range is limited to 31 bits.

The syntax of abstract heap types is extended with additional forms for the purpose of specifying validation and execution.

2.3.5. Reference Types

Reference types classify values that are first-class references to objects in the runtime store.

A reference type is characterised by the heap type it points to.

In addition, a reference type of the form $$\mathsf{ref}\mathsf{null}ht$$ is nullable, meaning that it can either be a proper reference to $$ht$$ or null. Other references are non-null.

Reference types are opaque, meaning that neither their size nor their bit pattern can be observed. Values of reference type can be stored in tables but not in memories.

2.3.6. Value Types

Value types classify the individual values that WebAssembly code can compute with and the values that a variable accepts. They are either number types, vector types, or reference types.

The syntax of value types is extended with additional forms for the purpose of specifying validation.

2.3.7. Result Types

Result types classify the result of executing instructions or functions, which is a sequence of values, written with brackets.

2.3.8. Block Types

Block types classify the input and output of structured control instructions delimiting blocks of instructions.

They are given either as a type index that refers to a suitable function type reinterpreted as an instruction type, or as an optional value type inline, which is a shorthand for the instruction type $$ϵ\to {valtype}^{?}$$.

2.3.9. Composite Types

Composite types are all types composed from simpler types, including function types, structure types and array types.

Function types classify the signature of functions, mapping a list of parameters to a list of results. They are also used to classify the inputs and outputs of instructions.

Aggregate types like structure or array types consist of a list of possibly mutable, possibly packed field types describing their components. Structures are heterogeneous, but require static indexing, while arrays need to be homogeneous, but allow dynamic indexing.

2.3.10. Recursive Types

Recursive types denote a group of mutually recursive composite types, each of which can optionally declare a list of type uses of supertypes that it matches. Each type can also be declared final, preventing further subtyping.

In a module, each member of a recursive type is assigned a separate type index.

2.3.11. Address Types

Address types are a subset of number types that classify the values that can be used as offsets into memories and tables.

2.3.12. Limits

Limits classify the size range of resizeable storage associated with memory types and table types.

If no maximum is present, then the respective storage can grow to any valid size.

2.3.13. Tag Types

Tag types classify the signature tags with a type use referring to the definition of a function type that declares the types of parameter and result values associated with the tag. The result type is empty for exception tags.

2.3.14. Global Types

Global types classify global variables, which hold a value and can either be mutable or immutable.

2.3.15. Memory Types

Memory types classify linear memories and their size range.

The limits constrain the minimum and optionally the maximum size of a memory. The limits are given in units of page size.

2.3.16. Table Types

Table types classify tables over elements of reference type within a size range.

Like memories, tables are constrained by limits for their minimum and optionally maximum size. The limits are given in numbers of entries.

2.3.17. Data Types

Data types classify data segments. Since the contents of a data segment requires no further classification, they merely consist of a universal marker $$\mathsf{ok}$$ indicating well-formedness.

2.3.18. Element Types

Element types classify element segments by the reference type of its elements.

2.3.19. External Types

External types classify imports and external addresses with their respective types.

For functions, the type use has to refer to the definition of a function type.

2.4.1. Parametric Instructions

Instructions in this group can operate on operands of any value type.

The $$\mathsf{nop}$$ instruction does nothing.

The $$\mathsf{unreachable}$$ instruction causes an unconditional trap.

The $$\mathsf{drop}$$ instruction simply throws away a single operand.

The $$\mathsf{select}$$ instruction selects one of its first two operands based on whether its third operand is zero or not. It may include a value type determining the type of these operands. If missing, the operands must be of numeric or vector type.

2.4.2. Control Instructions

Instructions in this group affect the flow of control.

The $$\mathsf{block}$$, $$\mathsf{loop}$$, $$\mathsf{if}$$ and $$try\_table$$ instructions are structured instructions. They bracket nested sequences of instructions, called blocks. As the grammar prescribes, they must be well-nested.

A structured instruction can consume input and produce output on the operand stack according to its annotated block type.

Each structured control instruction introduces an implicit label. Labels are targets for branch instructions that reference them with label indices. Unlike with other index spaces, indexing of labels is relative by nesting depth, that is, label $$0$$ refers to the innermost structured control instruction enclosing the referring branch instruction, while increasing indices refer to those farther out. Consequently, labels can only be referenced from within the associated structured control instruction. This also implies that branches can only be directed outwards, “breaking” from the block of the control construct they target. The exact effect depends on that control construct. In case of $$\mathsf{block}$$ or $$\mathsf{if}$$ it is a forward jump, resuming execution after the end of the block. In case of $$\mathsf{loop}$$ it is a backward jump to the beginning of the loop.

Branch instructions come in several flavors: $$\mathsf{br}$$ performs an unconditional branch, $$br\_if$$ performs a conditional branch, and $$br\_table$$ performs an indirect branch through an operand indexing into the label list that is an immediate to the instruction, or to a default target if the operand is out of bounds. The $$br\_on\_null$$ and $$br\_on\_non\_null$$ instructions check whether a reference operand is null and branch if that is the case or not the case, respectively. Similarly, $$br\_on\_cast$$ and $$br\_on\_cast\_fail$$ attempt a downcast on a reference operand and branch if that succeeds, or fails, respectively.

The $$\mathsf{return}$$ instruction is a shortcut for an unconditional branch to the outermost block, which implicitly is the body of the current function. Taking a branch unwinds the operand stack up to the height where the targeted structured control instruction was entered. However, branches may additionally consume operands themselves, which they push back on the operand stack after unwinding. Forward branches require operands according to the output of the targeted block’s type, i.e., represent the values produced by the terminated block. Backward branches require operands according to the input of the targeted block’s type, i.e., represent the values consumed by the restarted block.

The $$\mathsf{call}$$ instruction invokes another function, consuming the necessary arguments from the stack and returning the result values of the call. The $$call\_ref$$ instruction invokes a function indirectly through a function reference operand. The $$call\_indirect$$ instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must contain function references. Since it may contain functions of heterogeneous type, the callee is dynamically checked against the function type indexed by the instruction’s second immediate, and the call is aborted with a trap if it does not match.

The $$return\_call$$, $$return\_call\_ref$$, and $$return\_call\_indirect$$ instructions are tail-call variants of the previous ones. That is, they first return from the current function before actually performing the respective call. It is guaranteed that no sequence of nested calls using only these instructions can cause resource exhaustion due to hitting an implementation’s limit on the number of active calls.

The instructions $$\mathsf{throw}$$, $$throw\_ref$$, and $$try\_table$$ are concerned with exceptions. The $$\mathsf{throw}$$ and $$throw\_ref$$ instructions raise and reraise an exception, respectively, and transfers control to the innermost enclosing exception handler that has a matching catch clause. The $$try\_table$$ instruction installs an exception handler that handles exceptions as specified by its catch clauses.

2.4.3. Variable Instructions

Variable instructions are concerned with access to local or global variables.

These instructions get or set the values of respective variables. The $$\mathsf{local}.\mathsf{tee}$$ instruction is like $$\mathsf{local}.\mathsf{set}$$ but also returns its argument.

2.4.4. Table Instructions

Instructions in this group are concerned with tables table.

The $$\mathsf{table}.\mathsf{get}$$ and $$\mathsf{table}.\mathsf{set}$$ instructions load or store an element in a table, respectively.

The $$\mathsf{table}.\mathsf{size}$$ instruction returns the current size of a table. The $$\mathsf{table}.\mathsf{grow}$$ instruction grows table by a given delta and returns the previous size, or $$-1$$ if enough space cannot be allocated. It also takes an initialization value for the newly allocated entries.

The $$\mathsf{table}.\mathsf{fill}$$ instruction sets all entries in a range to a given value. The $$\mathsf{table}.\mathsf{copy}$$ instruction copies elements from a source table region to a possibly overlapping destination region; the first index denotes the destination. The $$\mathsf{table}.\mathsf{init}$$ instruction copies elements from a passive element segment into a table.

The $$\mathsf{elem}.\mathsf{drop}$$ instruction prevents further use of a passive element segment. This instruction is intended to be used as an optimization hint. After an element segment is dropped its elements can no longer be retrieved, so the memory used by this segment may be freed.

2.4.5. Memory Instructions

Instructions in this group are concerned with linear memory.

Memory is accessed with $$\mathsf{load}$$ and $$\mathsf{store}$$ instructions for the different number types and vector types <syntax-vectype>. They all take a memory index and a memory argument $$memarg$$ that contains an address offset and the expected alignment (expressed as the exponent of a power of 2).

Integer loads and stores can optionally specify a storage size $$sz$$ that is smaller than the bit width of the respective value type. In the case of loads, a sign extension mode $$sx$$ is then required to select appropriate behavior.

Vector loads can specify a shape that is half the bit width of $$\mathsf{v}128$$. Each lane is half its usual size, and the sign extension mode $$sx$$ then specifies how the smaller lane is extended to the larger lane. Alternatively, vector loads can perform a splat, such that only a single lane of the specified storage size is loaded, and the result is duplicated to all lanes.

The static address offset is added to the dynamic address operand, yielding a 33-bit or 65-bit effective address that is the zero-based index at which the memory is accessed. All values are read and written in little endian byte order. A trap results if any of the accessed memory bytes lies outside the address range implied by the memory’s current size.

The $$\mathsf{memory}.\mathsf{size}$$ instruction returns the current size of a memory. The $$\mathsf{memory}.\mathsf{grow}$$ instruction grows a memory by a given delta and returns the previous size, or $$-1$$ if enough memory cannot be allocated. Both instructions operate in units of page size.

The $$\mathsf{memory}.\mathsf{fill}$$ instruction sets all values in a regionof a memory to a given byte. The $$\mathsf{memory}.\mathsf{copy}$$ instruction copies data from a source memory region to a possibly overlapping destination region in another or the same memory; the first index denotes the destination The $$\mathsf{memory}.\mathsf{init}$$ instruction copies data from a passive data segment into a memory.

The $$\mathsf{data}.\mathsf{drop}$$ instruction prevents further use of a passive data segment. This instruction is intended to be used as an optimization hint. After a data segment is dropped its data can no longer be retrieved, so the memory used by this segment may be freed.

2.4.6. Reference Instructions

Instructions in this group are concerned with accessing references.

The $$\mathsf{ref}.\mathsf{null}$$ and $$\mathsf{ref}.\mathsf{func}$$ instructions produce a null reference or a reference to a given function, respectively.

The instruction $$\mathsf{ref}.is\_null$$ checks for null, while $$\mathsf{ref}.as\_non\_null$$ converts a nullable to a non-null one, and traps if it encounters null.

The $$\mathsf{ref}.\mathsf{eq}$$ compares two references.

The instructions $$\mathsf{ref}.\mathsf{test}$$ and $$\mathsf{ref}.\mathsf{cast}$$ test the dynamic type of a reference operand. The former merely returns the result of the test, while the latter performs a downcast and traps if the operand’s type does not match.

2.4.7. Aggregate Instructions

Instructions in this group are concerned with creating and accessing references to aggregate types.

The instructions $$\mathsf{struct}.\mathsf{new}$$ and $$\mathsf{struct}.new\_default$$ allocate a new structure, initializing them either with operands or with default values. The remaining instructions on structs access individual fields, allowing for different sign extension modes in the case of packed storage types.

Similarly, arrays can be allocated either with an explicit initialization operand or a default value. Furthermore, $$\mathsf{array}.new\_fixed$$ allocates an array with statically fixed size, and $$\mathsf{array}.new\_data$$ and $$\mathsf{array}.new\_elem$$ allocate an array and initialize it from a data or element segment, respectively. The instructions $$\mathsf{array}.\mathsf{get}$$, $$\mathsf{array}.\mathsf{get}sx$$, and $$\mathsf{array}.\mathsf{set}$$ access individual slots, again allowing for different sign extension modes in the case of a packed storage type; $$\mathsf{array}.\mathsf{len}$$ produces the length of an array; $$\mathsf{array}.\mathsf{fill}$$ fills a specified slice of an array with a given value and $$\mathsf{array}.\mathsf{copy}$$, $$\mathsf{array}.init\_data$$, and $$\mathsf{array}.init\_elem$$ copy elements to a specified slice of an array from a given array, data segment, or element segment, respectively.

The instructions $$\mathsf{ref}.\mathsf{i}31$$ and $$\mathsf{i}31.\mathsf{get}sx$$ convert between type $$\mathsf{i}32$$ and an unboxed scalar.

The instructions $$\mathsf{any}.convert\_extern$$ and $$\mathsf{extern}.convert\_any$$ allow lossless conversion between references represented as type $$(\mathsf{ref}\mathsf{null}\mathsf{extern})$$ and as $$(\mathsf{ref}\mathsf{null}\mathsf{any})$$.

2.4.8. Numeric Instructions

Numeric instructions provide basic operations over numeric values of specific type. These operations closely match respective operations available in hardware.